- 
                Notifications
    You must be signed in to change notification settings 
- Fork 152
Add support for mmaped memory in crashdumps and guest debugging #943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d463cbc    to
    c6e40e2      
    Compare
  
    | This looks good to me, but it looks like we're circumventing our SharedMemory abstraction here with unsafe code like from_raw. Would it be possible to avoid this? | 
| That is true, but I think this is a consequence of how the mmapped memory is handled. As a separate set of regions. | 
| 
 Oh yeah forgot about that... That might be unfeasible | 
c6e40e2    to
    d4fc726      
    Compare
  
    | I believe this PR touches on the Sandbox memory model discussion we need to have, specifically about how  | 
| 
 I think we should go forward with this as is and then address the winder memory issues in #956 | 
Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
d4fc726    to
    22ef548      
    Compare
  
    
Fixes #747 and is a blocker for hyperlight-dev/hyperlight-wasm#129.
This modifies the guest debugging by adding a
DebugMemoryAccesstype that handles the memory access for the debugger. It abstracts over the type of memory, shared or mmaped.Additionally, we now include the mmapped memory regions in the crashdump.